

# PV(访问量)：即Page View，页面刷新一次算一次。
# UV(独立访客)：即Unique Visitor，一个客户端（电脑，手机）为一个访客；


# 单体应用拆分--------------- 多个组件----------组件之间要独立数据库-------------api接口集成

# 微服务：  微服务组件模块  +  微服务组件暴露 api 接口的整合


# 微服务拆分 和 管控治理 --------没有做好造成------> 集成和运运维困难

# 》》》》》》》》》》》》》》》 -开发做的：--- 微服务 ---- 实现业务功能----暴露 api 接口


# 微服务接口管控-------> 放到微服务治理 （支持 运行态 动态 配置 调整）

# 去中心化治理平台在 管控各个 微服务 接口 




# 1  先定义 api 接口  ------- 输入输出 ，json 格式 评审 定下来 再开发  ------  过程中会发现很多问题需要改进
#         会发现  很多 都是数据接口（crud）  很多接口需要进一步去组合，形成领域接口， 对外暴露
#                             订单提交 --- 需要 运算接口，库存冻结 等，需要提供一个组合的api

# 2  接口运行监控，性能分析，告警预警，限流，---------->  会用到 api 网关  
#             1. 实例监控 ---  任何接口调用一次都会产生一个日志，【谁调用的，  调用的是谁 ，什么时候， 调用耗时， 调用的整体报文（输入输出）时什么样的， 数据量】
#             2. 异常日志： 系统异常（调用方异常，api网关异常） ， 中间件监控（内存使用，线程数）
#             3. 接口运行的统计分析： 运行次数，最大分钟数，异常数，告警数，服务最大运行时间，最小运行时间，消息最大报文、最小报文、平均报文长度-----可以按时间周期，组织服务


# 微服务划分： 1. 数据库 拆分：将相应的数据库表拆分到不同的数据库；  2. 上层的业务功能拆分，哪些服务聚合在一起
#             1 流程系统（oa）系统，根据不同流程拆分，很容易
#             2. 资产、资源管理这样 重的管理系统： 不能拆太细，不然会发生大量的跨库查询和大量的分布式事务，这样会极大的增加后期业务难度和管控治理难度

#             传统的拆分： 从端到端流程分析入手； 分解成大的几个阶段；------下一个阶段考虑数据库怎么拆---->
#                                     列出功能， 列出表，分析他们之间 crud 关系----- 将  cud 功能尽量聚合在一起（规避跨库操作）



# 为什么会出现前后端分离： 发生多个前端（浏览器、手机端、平板） 对应一个后端的适合

# api网关： 接入标准的 restful http 接口 粒度很细
# 微服务网关： 微服务模块对外的接口  ------  只管到微服务模块的粒度， 管不到微服务模块暴露的一个个api 接口

# 微服务 模块之间的调用的流量 不需要加入 网关（ 他们使用 服务 发现和 服务注册中心） 点对点调用  ---------- 去中心化架构
# 涉及到对外暴露，对外调用时会涉及到 api  网关  --------  中心化架构




# api 网关 需要持续集成  和 交付过程去做融合 ： 部署交付过程中  这个 微服务暴露的 api 接口可以 自动化注册接入到api网关


# 跨库查询： 1. 分库批量查询；  2. 将通用的查看提取出来做成一个通用的模块，打包成一个微服务


# 微服务内部：
# 服务 发现和 服务注册中心：  维护各个 微服务对外提供的 api
# 服务 拆分后 如果需要另一个  服务的api  可以在  注册发现中心 找， 找到了缓存到本地，然后本地直接调用，  查到数据口直接返回出去， 
# 当缓存建立完成后，即使注册中心挂了也不影响 对外提供服务

# 前端调用： 必须通过 微服务网关调用， 这个服务接口，并不是 api 接口， 它是多个 api 的集成体
